技術的には、広告ビジネスが関与しています AI アルゴリズム、ビッグデータ処理、検索エンジン、高性能、および使用可能なエンジニアリング アーキテクチャ 複数の方向など、同様に良い技術的な魅力を持っています。

私は昨年から広告ビジネスに手を差し出し、現在はほぼ1年です。 この記事は、広告システムの下で説明するために、業界の優れたケースを参照しながら、私の個人的な経験と組み合わせますスキーマ実践プログラムは、誰もが何かを得る願っています。内容は以下の3部構成：

• 広告ビジネスの概要
• 技術的な課題
• 広告システムアーキテクチャの詳細

01 広告ビジネスの概要

広告,どこでも言うことができます。WeChat,震えるトーン、B駅、バイドゥ、タオバオなどそして、これらの最も長いアプリは、どこでも広告の影を見ることができます。

広告は毎日どこでも表示され、その背後にあるビジネス ロジックはどのようなものですか。広告システムのアーキテクチャを共有する前に、皆さんを紹介します高速ですビジネス知識の普及。

1. 広告事業の核となるのはバランスです

なぜ広告ビジネスの中心です「バランス」? 広告の標準的な定義から理解することができます。

広告は次のように定義されます。広告主がインターネット プラットフォームを通じてユーザーに商品やサービスに関する情報を有料で配布する手段。 この定義に関連しています 広告主、プラットフォーム、ユーザー 3つのエージェントが,これら3つのエージェントの利害関係は異なる.

図1:広告事業の三角バランス

• 広告主:ROIに焦点を当て、お金を費やして期待される利益をもたらすかどうか

• プラットフォーム:トラフィックを所有し、収益を最大化できるかどうかに注目します

• ユーザー:エクスペリエンスに焦点を当て、広告は十分に正確ですか? 通常の機能の使用に影響しますか?
  

3. 広告のコアビジネスプロセス

図3:広告の中核となるビジネス プロセス

• 広告主は、まずプラットフォームに広告を掲載し、都市、期間、群衆タグ、入札単価など、一連のターゲット設定条件を設定できます。

• 配信が完了すると、広告は広告ライブラリに保存され、インデックス ライブラリに入り、広告検索エンジンによってリコールされます。

• C側が要求すると、広告エンジンはリコール、アルゴリズム戦略、オークションソートなどの一連のロジックを完了し、最終的にTop N広告をフィルタリングし、広告の千の顔を実現します。
  

• ユーザーが広告をクリックすると、広告の請求プロセスがトリガーされ、プラットフォームが真の収益を得ることができます。

1、高い同時実行:広告エンジンとC側トラフィックドッキング、要求量(Pingfengは、多くの場合、QPSの数万を持っている)、要件リアルタイムで応答の場合、結果は数十ミリ秒以内に返される必要があります。

2、ビジネス ロジックは複雑です: 複数のリコール、アルゴリズム モデルのスコア付け、オークションの並べ替えなどの複雑なビジネス プロセスを含む広告要求。

3、安定性要件が高い:広告システムは、収益に直接リンクされ、広告エンジンや課金プラットフォームなどのコアシステムの安定性は非常に高く、可用性は少なくとも3つの9を達成する必要があります。

4、ビッグ データ ストレージとコンピューティング: 事業の成長に伴い、プロモーション数量と請求注文数は数千万または数十億に達する可能性があり、収益レポートの集計ディメンションが多く、単一レポートは 100 億レベルのレコード数に達する可能性があります。

5、会計の正確性:広告控除は、金融の性質の操作であり、失われないようにする必要があり、繰り返し、そうでなければ、特定の当事者の利益を害します。 また、収益データが不正確な場合、ビジネス上の意思決定にも影響する可能性があります。

広告ビジネスの目的と技術的課題を理解したら、広告システムの全体的なアーキテクチャと技術ソリューションについて詳しく説明します。

図4:広告システムの全体的なアーキテクチャ

それは私たちの会社です目前に広告システムアーキテクチャ図、このアーキテクチャは、広告ビジネスの初期段階で動作します。がターゲットです「独自のスポットネットワークとインサイトトラフィックは、アフィリエイト広告には関与しません。

• 広告配信システム: 広告主様の場合、メンバーシップの更新、広告ライブラリの管理、プロモーション条件の設定、広告入札の設定、掲載結果の表示などのコア機能を利用できます。

• 広告業務のバックオフィス: プラットフォームの製品運用に使用され、広告プラットフォーム管理、広告ポリシー管理、さまざまな運用ツールなどのコア機能を備えています。

• 広告検索プラットフォーム:C側の高同時要求を受け、大規模な広告ライブラリから数または数十の広告をフィルタリングする責任があり、リアルタイム性要件は高く、このプラットフォームは、通常、複数のマイクロサービスで構成されています。

• AB実験プラットフォーム:広告ビジネスのスタビライザーは、任意の広告戦略の調整は、このプラットフォームを介してグレースケール実験を行い、収益指標の変化を観察することができます。

• 広告請求プラットフォーム:C側向けで、リアルタイムの手数料控除を担当し、収益に直接リンクし、可用性要件が高い。

• 会計管理センター:広告事業における金融システム、リチャージ、凍結、手数料の源泉徴収など、金額関連業務を統管理します。

• ビッグデータプラットフォーム:広告システム全体のシャーシは、さまざまな異種データソースを集約し、オフラインおよびリアルタイムのデータ分析と統計を完了し、ビジネスレポート、生産モデルの特性などを生成する必要があります。

1. 広告データの保存

広告システムは、さまざまなデータを格納し、異なる特性を採用していますですマルチモード データの保存方法。

図 5: 広告データのマルチモード ストレージ

• 広告ライブラリ、クリエイティブライブラリ、メンバーシップライブラリ、広告製品ライブラリ、広告戦略ライブラリなどを含むOLTPシーンは、MySQLに保存され、より大きな広告ライブラリとクリエイティブライブラリのデータは、広告主ID Hashに従ってセクションテーブル化されます。

• OLAP シナリオは、非常に多くのレポート、集計ディメンション、および HDFS と HBase ストレージの基になる 100 億レベルに達する単一テーブルレコードを含むシナリオです。

• Redis と ES を使用して格納される、正のインデックスと反転インデックスを含む、広告検索シナリオのインデックス データ。

図 6: 広告インデックス更新しますプロセス

インデックス更新サービスには、いくつかの重要なポイントがあります。

• 各業務システムは,プロモーション,残高などの情報変更時にMQメッセージを送信し,インデックス更新サービスはMQを購読して変化を感知し,増分同期を完了する.

• 変更されたメッセージ本文では,実際に変更されたフィールドは渡され,変更された広告IDのみが通知され,インデックス更新サービスはリアルタイムで最新のデータを読み取って更新を完了し,メッセージの乱れによるデータ不整合を効果的に解決できる.

• インデックスの更新が一定のレベルに達したら、同じ広告の変更をマージするか、反転と正の更新を分離します言及全体の更新速度を上げる。
  

2. 広告検索プラットフォームの全体的なプロセス

広告検索プラットフォームは、C側のトラフィック要求を引き受け、大規模な広告ライブラリから最も適切な上位Nの広告をフィルタリングし、数十ミリ秒以内に結果を返す責任があります。

Recall層はアルゴリズムモデルに,Search層は業務に重きを置く. 下から上へ、計算の複雑さは層ごとに増加し、候補セットは層ごとに減少します。 (説明:検索広告シーンと紹介広告シーンは、一部のサブモジュールで異なりますが、全体的なプロセスは基本的に一貫していますが、ここでは展開しません)

パフォーマンス設計は、検索プラットフォームの焦点であり、通常、次の手段があります。

• サービスの階層化をうまく行い、各層を水平方向に拡張できます。

• Redis キャッシュを使用すると、高同時要求がデータベースに直接ヒットすることを回避し、キャッシュはビジネス計画に従って複数のセットを流用できます。

• マルチスレッドリコールロジック、マルチモデルスコアロジックなど、いくつかのサブプロセスをマルチスレッド並列化します。

• ホット スポット データは、広告マネージャの構成情報やポリシー構成情報などのローカル キャッシュに使用されますサービスの開始時にローカルにプリロードし、同期をスケジュールできます。

• 非コア プロセスプレミアム戦略などのダウングレード ロジックを溶断するタイムアウトを設定します (プレミアムは広告のリコールに影響を与えなく、単に少ない収入です)。

• とメイン プロセスに依存しない論理非同期実行，たとえば、請求情報などですゆっくりと保存します、リコール結果キャッシュなど

• シン RPC は結果または Redis キャッシュ オブジェクトの構造を返し、不要なフィールドを削除し、IO パケット サイズを削減します。

• JVM ヒープ メモリを含む GC 最適化設定、ガベージ コレクタの選択、GC 頻度の最適化、および GC の時間のかかる最適化。
  

3. 課金プラットフォームの技術スキーム

まず,課金プロセス全体が非同期化され,リアルタイム課金要求を受信すると,システムはまず課金に費やした情報をRedisにキャッシュし,その後MQメッセージを送信し,この2つのステップが完了すると課金動作が終了する.

この利点は、MQ の信頼性ドロップと再試行メカニズムを使用して、請求プロセス全体の最終的な一貫性を確保しながら、課金インターフェイスのパフォーマンスを確保することです。

可用性を向上させるために、Redis と MQ が使用できない場合のダウングレード スキームが採用されています。 Redis が使用できない場合は、永続化のために TiKV に切り替え、MQ ドロップが失敗した場合はスレッド プール非同期処理に切り替えます。

また、有効なクリックごとに1つの請求注文を生成する必要があり、ビッグデータのストレージの問題に直面しています。 現在、MySQL ライブラリ テーブルを使用していますが、HBase などの分散ストレージの使用は後で検討されます。 さらに、注文と会計システム間のデータの一貫性は、ビッグデータプラットフォームを使用して、Hiveタスクを介して調整と監視を完了するために、毎日の増分抽出を行います。

図 9: 広告データ ウェアハウスの階層構造

• ソース データ層: を含むさまざまなソース データに対応しますHDFS でリアルタイムに収集されますフロントバックエンドログ、増分またはフルボリューム同期MySQLビジネスデータテーブル。

• データ ウェアハウス層: ディメンション テーブルとファクト テーブル (通常は、動作ログ テーブル、プロスペクト ワイド テーブル、ユーザー ワイド テーブルなど) をクリーニングした後のデータ ワイド テーブルを含みます。

• データ マート層: 広告効果テーブル、ユーザー行動のフルリンクテーブル、ユーザーベース分析テーブルなど、データの軽量で詳細な集計テーブル。

• データ アプリケーション層: 多次元分析によって生成されたさまざまな収益レポート、Spark タスク出力のアルゴリズム モデル特性、画像データなど、上層のシナリオで直接使用されるデータ テーブル。

最後に書いてください

（終わりだ）

場合は、元の記事の著者です

投稿へようこそ(アプリーマーコードを長押しして提出)